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TELNET OUTPUT LINEFEED DISPOSITION 


Command name and code 
NAOLFD 16 
(Negotiate About Output Linefeed Disposition) 


Command meanings 
In the following, we are discussing a simplex connection, as described in 
the NAOL and NAOP Telnet Options. 
IAC DO NAOLFD 
The data sender requests or agrees to negotiate about output 
linefeed disposition with the data receiver. In the case where 
agreement has been reached and in the absence of further 
subnegotiations, the data receiver is assumed to be handling output 
linefeed considerations. 
IAC DON’ T NAOLFD 
The data sender refuses to negotiate about output linefeed 
disposition with the data receiver, or demands a return to the 
unnegotiated default mode. 
IAC WILL NAOLFD 
The data receiver requests or agrees to negotiate about output 
linefeed disposition with the sender. In the case where agreement 
has been reached and in the absence of further subnegotiations, the 
data receiver alone is assumed to be handling output linefeed 
considerations. 
IAC WON’ T NAOLFD 
The data receiver refuses to negotiate about output linefeed 
disposition, or demands a return to the unnegotiated default mode. 
TAC SB NAOLFD DS <8-bit value> IAC SE 
The data sender specifies, with the 8-bit value, which party should 
handle output linefeeds and what their disposition should be. The 
code for DS is 1. 
TAC SB NAOLFD DR <8-bit value> IAC SE 
The data receiver specifies, with the 8-bit value, which party 
should handle output linefeeds and what their disposition should 
be. The code for DR is 0. 


Default 

DON’T NAOLFD/WON’T NAOLFD. 
In the default absence of negotiations concerning which party, data 
under or data receiver, is handling output linefeed considerations, 
neither party is required nor prohibited from handling linefeeds; but 
it is appropriate if at least the data receiver handles them, albeit 
primitively. 


Motivation for the Option 
Please refer to section 4 of the NAOL and of the NAOLFD Telnet option 


descriptions. 


Ds 


Description of the Option 
The data sender and the data receiver use the 8-bit value along with DS 
and DR SB commands as follows: 


8-bit value Meaning 

0 Command sender suggests that he alone will handle 
linefeeds, for the connection. 

1 to 250 Command sender suggests that the other party alone 


should handle linefeeds, but suggests that a delay 
of the indicated value be used. The value is the 
number of character-times to wait or number of 
NULs to insert in the data stream before sending 


the next data character. (See qualifications, below.) 
251 Not allowed, in order to be compatible with 

related Telnet options. 
252 Command sender suggests that the other party alone 

handle linefeeds, but suggests that they be discarded. 
253 Command sender suggests that the other party alone 


should handle linefeeds, but suggests that 
linefeeds be simulated. 

254 Command sender suggests that the other party alone 
should handle output linefeeds but suggests 
waiting for a character to be transmitted (on the 
other simplex connection) before sending more 
data. (See qualifications, below.) Note that, due 
to the assynchrony of the two simplex connections, 
phase problems can occur with this option. 

259 Command sender suggests that the other party alone 
should handle output linefeeds and suggests 
nothing about how it should be done. 


The guiding rules are that: 


1) if neither data receiver nor data sender wants to handle output 
linefeeds, the data receiver must do it, and 

2) if both data receiver and data sender want to handle output linefeed 
disposition, the data sender gets to do it. 


The reasoning for the former rule is that if neither wants to do it, then 
the default in the NAOLFD option dominates. If both want to do it, the 
sender, who is presumed to have special knowledge about the data, should 
be allowed to do it, taking into account any suggestions the receiver may 
make. Simulation is defined as the replacement of the linefeed character 
by new-line (see following) and enough blanks to move the print head (or 
line pointer) to the same lateral position it occupied just prior to 
receiving the linefeed. To avoid infinite recursion, such simulation is 
allowed only for linefeed characters that are not immediately preceded by 
carriage-returns (that is, part of a Telnet new-line combination). It is 
assumed that linefeed simulation will be necessary for printers that do 
not have a separate linefeed (like the IBM 2741); in this case, 
end-of-line character padding can be specified through NAOCRD. Any 
padding (0 < <8-bit-value> < 251) of linefeed characters is to be done 
for ALL linefeed characters. 


NOTE: Delays, controlled by the data sender, must consist of NUL 
characters inserted immediately after the character. This is necessary 
due to the assynchrony of network transmissions. Additionally, due to 
the presence of the Telnet end-of-line convention, it may be necessary to 
add carriage-return padding or delay after the associated linefeed (see 
NAOCRD Telnet option). As with all option negotiations, neither party 
should suggest a state already in effect except to refuse to negotiate; 
changes should be acknowledged; and once refused, an option should not be 
resuggested until "something changes" (e.g., another process starts). At 
any time, either party can disable further negotiation by giving the 
appropriate WON’T NAOLFD or DON’T NAOLFD command. 


